1. Field of the Invention
The present invention is generally related to a system of processing software programs directed to computer operations and, more particularly, is related to a system and method for replacing a running program""s code within the same process in software.
2. Description of Related Art
As known in the computer and software arts, software programs undergo many changes during its product life. The changes either enhance the system through updates or remove problems (i.e., bugs) from the program steps. In either circumstance, the software program must be replaced with a new version of the program.
Typically, when a software program is replaced with a new version, the old version of the program is terminated and the new version is started. This procedure, however, creates the problem where the program operation is interrupted for some time period.
While there are some solutions for on-line software version changes, these techniques suffer from the following problems. One problem is that operating systems designed to allow software program updates on-line or on-the-fly, must use indirect addressing tables to link different modules together utilizing complicated mechanisms. The use of indirect addressing tables impacts the performance of the overall system software.
The prior art also suffers the problem of transferring the state from the old process to the new process, along with transferring control using the stack monitoring system. However, this transferring of the state to the new version program in the new process suffers the following performance problems.
First, the main function of the program can never change in the old version or the new version.
It is also assumed that while the stack can be used and transferred from the old program in the old process to the new program in the new process, it implies that no new procedure area layers can be added because they would cause errors in the processing since they would be returning to procedures at different addresses.
Furthermore, when transferring control from an old version of a program in an old process to a new version of a program in a new process, the assumption that the program counter can be converted implies that the offset to a function or procedure may never change due to the offset addressing within the version of the program.
Transferring from an old program/process to a new version program/process also assumes that no extra global or static variables can be added or deleted since this would cause errors in the execution of the new program/process.
Next, the transfer from an old program/process to a new version program/process implies that the addresses of the data remain constant across the two version, i.e., there is no reordering or optimization changes, etc.
The return value or parameter format changes required that an intraprocedure be written that adds extra overhead on each function call and makes it more difficult to maintain the software.
Additionally, stack monitoring techniques cannot guarantee that the old program/process is not performing a time critical task when the state transfer routine is initiated.
Also, the new program/process loses attributes associated with the old process such as the process ID, all the network connections, file connections, and the like, when the old process is terminated to restart within the new process.
In addition, to initiate state transfer one must insert an illegal instruction and assume there can be no other causes for this illegal instruction or trap, which would thereby make it possible to initiate a state transfer at the wrong time.
Heretofore, software users have lacked the ability to allow a program running in a process to be replaced with a new version of a program within the same process without loss of service or state.
The present invention is generally directed to an apparatus and method for on-line code replacement of a computer program running in a software process. In accordance with one aspect of the invention, the apparatus and method utilize a proposed variant of the UNIX(trademark) exec system call, which will be referred to as a text-only exec.
In accordance with another embodiment of the apparatus and method of the present invention, a checkpoint methodology allows the programmer maximum flexibility in addressing upgrade/replacement program issues and determines where, when and how the transition to a new version of a program should occur with least impact to the services.
In accordance with another embodiment of the present invention, procedures have complete flexibility to change arguments or return values and change calling order, function names, function code and the like within the new version of the program since stack monitoring techniques are not being used.
In accordance with yet another embodiment, the present invention preserves all state based network connections during the transition to a new version of a program.